「実践 Amazon KMS」補遺

こんにちは、虎塚です。

今日は、以前イベントでお話しした「実践 Amazon KMS」の内容について、当日や後日いただいたご質問への回答をまとめたいと思います。

Q1. データキーを暗号化したマスターキーを覚えておく必要がある？

「データキーを暗号化するのに使ったマスターキーを覚えておかないと、データキーを復号できませんか？」というご質問がありました。

回答は「いいえ、覚えておく必要はありません」です。

詳細

KMSを使った暗号化では、概念的には次の2段階で鍵を使用します。

1. 保護したい情報を、データキーで暗号化する
2. 暗号化に使用したデータキーを、マスターキーで暗号化する

APIを利用した実際の操作としては、次のようになります。

1. 暗号化されたデータキーと暗号化されていないデータキーを受け取る
2. 暗号化されていないデータキーで、保護したい情報を暗号化する
3. 暗号化されていないデータキーを削除する
4. 暗号化されたデータキーだけを（復号にそなえて）保管する

1つ目のステップで、暗号化されたデータキーを取得するために用意されているAPIは、次の3種類です。

• データキーを生成して暗号化するAPI
  • generate-data-key
  • generate-data-key-withoud-plaintext
• データキー（のように小さなデータ）を暗号化するAPI
  • encrypt

上記3種類のAPIは、引数に「データキーを暗号化するマスターキーのID」を指定して利用します。次の図は、generate-data-key APIの例です。

一方、データキーを復号するために、decryptというAPIが用意されています。このAPIの引数は、「暗号化されたデータキーそのもの」だけです。

上の図でいうと、CiphertextBlobが、暗号化されたデータキーを意味します。データキーを暗号化するのに使ったマスターキーは、指定する必要がありません。非対称のように感じるかもしれませんが、KMSの仕組み上、そうなっています。

（なお、発表時に、decrypt APIの説明で誤って「KeyId」を引数に渡している図を使ったために、こちらの質問をいただいたのではないかと思います。資料を訂正いたします。申し訳ありません）

補足

ちなみに、データキーを生成する際に、encryption-contextという任意のkey-value形式の文字列を引数に指定できます。この値はオプションです。

データキー生成時にこの値を使用した場合は、データキー復号時にも同じ文字列を指定しなければなりません。保管しておかなければならないのは、暗号化に使ったマスターキーでなく、こちらの値です。

Q2. RDSの暗号化に使った鍵をDisableしてもう一度Enableしたらどうなる？

「RDSの暗号化に使ったカスタマーマスターキーを無効化した場合、そのキーをもう一度有効化しても、暗号化対象のデータベースは正常に戻らないのか？」という質問を同僚から受けました。

回答は、「はい、戻りません！ そのDBインスタンスはもうダメです……」です。カスタマーマスターキーの無効化には、細心の注意を払ってください。

詳細

公式ドキュメントのとおり、DBインスタンスの暗号化に使用したキーを無効化するなどして、AWSからキーにアクセスできなくなった場合、たとえキーを後から再有効化しても、DBインスタンスは終了状態になります。DBインスタンスのバックアップからリストアするしかありません。

• Amazon RDS リソースの暗号化 - Amazon Relational Database Service

このような事態にそなえて、RDS暗号化にKMSを使うことにした場合は、DBの自動バックアップをかならず有効にしておきましょう。

Q3. カスタマーマスターキーを使う積極的な理由は？

上記のように、カスタマーマスターキーを誤って無効化することの危険性は、デフォルトマスターキーを使えば解決します。デフォルトマスターキーは、AWSによってあらかじめ用意されたマスターキーです。デフォルトマスターキーは、ユーザ操作によって無効化できません。

という話をしたところ、「それならデフォルトマスターキーではなく、カスタマーマスターキーを使う積極的な理由はあるの？（どんな時でもデフォルトマスターキーを使えばよいのでは？）」という質問を同僚から受けました。

回答は、「複数のキーポリシーを使い分けたい場合は、カスタマーマスターキーが便利です！」です。

詳細

キーポリシーとは、キーに対する操作の権限を定義したものです。

デフォルトマスターキーの場合、ポリシーもAWSから提供され、ユーザは内容を変更できません。また、デフォルトマスターキーは、リージョンごと、サービスごと（RDS、S3、ELB、Redshiftなど）に1本だけ提供されます。たとえば、東京リージョンのS3バケットを暗号化するために利用できるデフォルトマスターキーは、1種類しかありません。当然、利用できるポリシーも1種類です。

一方、カスタマーマスターキーでは、ユーザが自由にポリシーを作成して適用できます。また、リージョンに複数作成できます。複数のポリシーを用途に応じて使い分けるには、カスタマーマスターキーが便利でしょう。

Q4. データキーは無効化できる？

「カスタマーマスターキーが有効化/無効化できるのは分かったけど、データキーは削除や無効化ができるのか？」という質問を同僚から受けました。

回答は「データキーを明示的に無効化するAPIは存在しません」です。

とはいえ、ユースケースとして、「作成済みの暗号化されたデータキーを、ある時点以降は復号に利用されたくない」という場合があるかもしれません。それには、次の対処法があります。

• ユーザが特定できる場合、そのユーザによるDecrypt操作をキーポリシーで禁止する
• ユーザが特定できない場合、マスターキーを無効化する

しかし、複数のサービスでマスターキーを共用していると、Q2で挙げたような制約が発生し、安易にキーを無効化できない状況に陥ることが考えられます。データキーの暗号化に使うマスターキーは、用途によって使い分けたほうがよいと思います。

おわりに

質問してくださった皆さん、ありがとうございました。不明点は解決しましたでしょうか？

他にもこういった話題が出てきましたら、また補遺をホイホイと書いていきたいと思います。ご質問、ツッコミ等、ぜひよろしくお願いいたします。

それでは、また。